fix(tor): stop Tor from silently disabling Moshpit resolution - #54
Merged
Conversation
With Tor on, only loopback bypassed the SOCKS proxy, so the registry lookup that sits in front of every Moshpit navigation went out over Tor. A cold circuit does not answer inside the lookup budget, the lookup returns null, and resolution falls back to clearnet — which is the correct failure mode for a registry that is down, and completely wrong for one that was merely slow. The symptom is a Moshpit name resolving as an ordinary domain, indistinguishable from the name not existing. The pit's own hosts now bypass Tor alongside loopback. Built from the configured bases rather than hardcoded, so a self-hosted pit gets the same treatment as the public one, and read at enable time because the options page can repoint the registry between one toggle and the next. The privacy trade is deliberate and written down next to the code: bypassing means the network path sees which Moshpit names are looked up and the registry sees the real IP. Neither was hidden before — the registry is told the name either way, and the console is where the account is signed in — so Tor was protecting close to nothing on this leg, at the cost of the feature working. The lookup budget goes 4s -> 8s in both the TS module and its extension port. 4s was tight for a phone on a bad connection; it is a budget for a check that blocks navigation, not a guess at a worst case, and exceeding it still falls back to clearnet. 7 new tests, including that both ports agree on the budget — the two copies of this policy already have a faithfulness test and this keeps it honest. 91 across the desktop suite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
apps/desktop/package-lock.json was never tracked; it appeared because the previous commit's tests were run with npm in a fresh worktree. This repo is pnpm@9.12.0 with a single pnpm-lock.yaml, and a stray npm lockfile beside it is a second, disagreeing source of truth for the same dependency tree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
Merged
ralyodio
added a commit
that referenced
this pull request
Jul 31, 2026
Ships the Tor fix (#54): with Tor on, only loopback bypassed the SOCKS proxy, so the registry lookup in front of every Moshpit navigation went out over Tor. A cold circuit does not answer inside the lookup budget, so resolution fell back to clearnet — correct for a registry that is down, wrong for one that was merely slow, and indistinguishable from the name not existing. The pit's own hosts now bypass Tor alongside loopback, computed from the configured bases so a self-hosted pit is covered too. The lookup budget goes 4s -> 8s in both the policy module and its extension port. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
With Tor on, only loopback bypassed the SOCKS proxy:
So the registry lookup that sits in front of every Moshpit navigation went out over Tor. A cold circuit doesn't answer inside the 4s lookup budget →
lookupMoshpitreturnsnull→ resolution falls back to clearnet.That's the correct failure mode for a registry that's down, and completely wrong for one that was merely slow. The symptom is a Moshpit name resolving as an ordinary domain — indistinguishable from the name not existing. Nothing errors, nothing logs, the feature just stops working while Tor is on.
The fix
The pit's own hosts now bypass Tor alongside loopback. Built from the configured bases rather than hardcoded, so a self-hosted pit gets the same treatment as the public one, and read at enable time because the options page can repoint the registry between one toggle and the next.
Lookup budget goes 4s → 8s in both the TS module and its extension port. 4s was tight for a phone on a bad connection. It's a budget for a check that blocks navigation, not a guess at a worst case — exceeding it still falls back to clearnet.
The privacy trade, stated plainly
Bypassing means the network path sees which Moshpit names are looked up, and the registry sees the real IP.
Neither was hidden before: the registry is told the name either way, and
app.moshcode.shis where the account is signed in. So Tor was protecting close to nothing on this leg, at the cost of the feature working at all. The reasoning is in a comment next tomoshpitBypassHostsso the next person can disagree with it on the merits.This does not change
.onionhandling — SOCKS5 still resolves DNS at the proxy for everything not on the bypass list.Tests
7 new, including that both ports agree on the budget —
moshpit.jsis a hand port ofmoshpit-resolve.tsand already has a faithfulness test; this keeps the new constant honest. Edge cases covered: self-hosted base, port stripping, unparseable/missing bases (throwing here would leave the proxy unset while the badge says TOR).91/91 across the desktop suite.
🤖 Generated with Claude Code